home *** CD-ROM | disk | FTP | other *** search
/ AOL File Library: 4,101 to 4,200 / aol-file-protocol-4400-4101-to-4200.zip / AOLDLs / ADV - Message Board Archives / Archived Msgs_ CDA's / ADV.CDA.shk / ADV.CDA.LOG
Text File  |  1992-09-13  |  23KB  |  786 lines
  1.  
  2. =======================================================================
  3. Archived Messages: "CDA's"
  4. America Online Apple II Developers Forum.
  5. Go Keyword ADV!
  6. (C) 1992.
  7. ===================================================================jrm=
  8.  
  9. Type:      Response       
  10. From:      KatherineL
  11. Date:      88-02-15 22:27:19 EST
  12. 88-02-15 22:27:19 EST
  13. CC:        KatherineL
  14. Re:        Re: CDA's
  15.  
  16. I'd like to develop a CDA using TML Pascal.  My question is, how do I write and
  17. read from the screen?  Standard Pascal I/O is out because TML uses SHR for
  18. that.  Any suggestions?  I also have APW C -- would it be easier to use that?
  19.  
  20.  
  21.  
  22. Type:      Response       
  23. From:      FL Jim
  24. Date:      88-02-16 00:02:13 EST
  25. Re:        Re: CDA's
  26.  
  27. Kathy,
  28. The version 1.1 of TML Pascal lets you use the text screen. Just leave the
  29. (INPUT,OUTPUT) identifiers off the program heading. If you find that readln
  30. doesn't work with the text screen, then you need to send your TML Pascal disk
  31. back for the 1.1A update (it's free).
  32. --Jim
  33.  
  34.  
  35.  
  36. Type:      Response       
  37. From:      KatherineL
  38. Date:      88-02-16 23:50:05 EST
  39. 88-02-16 23:50:05 EST
  40. CC:        KatherineL
  41. Re:        Re: CDA's
  42.  
  43. I'll check it out.  If I don't have 1.1a I just ordered 1.50 so that should do
  44. it for me!  Let you know.  Thanks.  :)
  45.  
  46.  
  47.  
  48. Type:      Response       
  49. From:      KatherineL
  50. Date:      88-02-20 18:18:47 EST
  51. 88-02-20 18:18:47 EST
  52. CC:        KatherineL
  53. Re:        Re: CDA's
  54.  
  55. The ongoing saga of the broken CDA continues over in Pascal for those who are
  56. interested...
  57.  
  58.  
  59.  
  60. Type:      Response       
  61. From:      KatherineL
  62. Date:      88-02-20 18:32:48 EST
  63. 88-02-20 18:32:48 EST
  64. CC:        KatherineL
  65. Re:        Re: CDA's
  66.  
  67. Is there a maximum allowable size for a CDA?  Aside from the memory constraints
  68. of the machine as a whole (wouldn't be nice to write a 256K CDA in case you
  69. have a user with only 256K! :)  ).
  70.  
  71.  
  72.  
  73. Type:      Response       
  74. From:      AFL Jim
  75. Date:      88-05-29 14:13:41 EST
  76. Re:        Re: CDA's
  77.  
  78. Which type of desk accessory do programmers prefer?  CDAs can be accessed from
  79. any type of program, but you can't see what your program is doing while the CDA
  80. is active. NDAs can only be accessed from the SHR desktop environment, but they
  81. run inside a window so desktop applications can be watched while you run the
  82. NDA. I've got some ideas for programming utility DAs and I'm looking for your
  83. input.
  84.  
  85. Jim
  86.  
  87.  
  88.  
  89. Type:      Response       
  90. From:      User797
  91. Date:      88-05-30 19:47:28 EST
  92. 88-05-30 19:47:28 EST
  93. CC:        KatherineL
  94. Re:        Re: Preferred DA's
  95.  
  96. For me, it depends entirely upon the nature of the DA.  If it's the type of
  97. thing (like a phone dialer or calculator) that I may want in AppleWorks or my
  98. other P8 applications, then a CDA is the obvious answer.  If the DA is only
  99. useful in a window environment (like a mouse follower or event reporter), then
  100. an NDA is more appropriate.  I'm leaning a bit toward CDA's these days.  Many
  101. accessory functions are most useful when opened for a moment, then shut down. 
  102. NDA's don't handle this very well, and are expected to stay on the screen until
  103. otherwise informed.  I don't like that.  Hope this helps.
  104.  
  105.  
  106.  
  107. Type:      Response       
  108. From:      Parik Rao
  109. Date:      88-05-30 22:11:35 EST
  110. 88-05-30 22:11:35 EST
  111. CC:        KatherineL
  112. Re:        Re: CDA's
  113.  
  114.  
  115. I personally prefer CDAs, but like User797 said, it depends on
  116. the utility itself.  However, CDAs are more versatile, since I
  117. can use them in ProDOS 8, or in the middle of a non-desktop environment that
  118. supports interrupts.  NDAs are just too limited
  119. to be of much use, due to the time I spend in any given desktop (Orca Desktop
  120. is about the only one).
  121.  
  122. Or how about just programming two versions?  Both structures are
  123. pretty much the same, just a few tool-call changes and format
  124. changes, and you have the same thing.  You can easily change one
  125. to another...
  126.  
  127.  
  128.  
  129.  
  130. Type:      Response       
  131. From:      AIIDTS
  132. Date:      88-06-02 18:29:57 EST
  133. 88-06-02 18:29:57 EST
  134. CC:        KatherineL
  135. Re:        Re: CDA's
  136.  
  137. for programming utilities, CDA's are the only way to go for me. NDA's require
  138. the machine to be in a perfectly running state, which ain't always the case
  139. when you are developing software.
  140.  
  141. As for the CDA's I use most, well I can tell you that I only use 1 CDA in all
  142. the ones I have ever had. That CDA gets used ALL the time, its called Nifty
  143. List, and if you are developing GS software this is a MUST! ( at least I think
  144. so) it is shareware and well worth the price.
  145.  
  146. Jim
  147.  
  148.  
  149.  
  150. Type:      Response       
  151. From:      Parik Rao
  152. Date:      88-06-02 20:49:59 EST
  153. 88-06-02 20:49:59 EST
  154. CC:        KatherineL
  155. Re:        Re: CDA's
  156.  
  157.  
  158. Also another great one is Memory Peeker... its great when your
  159. program crash's or you want to see if your program is storing
  160. data correctly w/o having to insert the actual code in your program.
  161.  
  162.  
  163.  
  164.  
  165. Type:      Response       
  166. From:      AFL Floyd
  167. Date:      88-06-02 21:56:16 EST
  168. 88-06-02 21:56:16 EST
  169. CC:        KatherineL
  170. Re:        Re: CDA's
  171.  
  172. Nifty List is a NECECESSITY for programmers.  I use it EVERYDAY!  It does MUCH
  173. more than memory peeker or any other CDA that I have seen.
  174.  
  175. Floyd
  176.  
  177.  
  178.  
  179. Type:      Response       
  180. From:      ScottG25
  181. Date:      88-06-03 17:28:15 EST
  182. 88-06-03 17:28:15 EST
  183. CC:        KatherineL
  184. Re:        Re: CDA's
  185.  
  186. I agree totally on the usefulness of Nifty List...The thing is a gem!
  187.  
  188.  
  189.  
  190. Type:      Response       
  191. From:      JSchober
  192. Date:      88-06-03 19:42:24 EST
  193. 88-06-03 19:42:24 EST
  194. CC:        KatherineL
  195. Re:        Re: CDA's
  196.  
  197. Parik... Nifty List contains some of the same functions that Memory Peeker does
  198. (NL allows you to display all memory allocated at the time, or get info on a
  199. specific ApplID), and you can still go into the Monitor from it! I personally
  200. just hit a # when I boot up, then run ORCA/GS just so I can install NL. (Don't
  201. have a CDA version of it, so I can't use P8CDA... sigh...) Dunno what I did
  202. without that one!!!
  203.  
  204.  
  205.  
  206. Type:      Response       
  207. From:      AFL Floyd
  208. Date:      88-06-04 10:37:58 EST
  209. 88-06-04 10:37:58 EST
  210. CC:        KatherineL
  211. Re:        Re: CDA's
  212.  
  213. The CDA version of Nifty List is in "IIGS Desk Accessories" in the Utilities
  214. Forum.  If you use this great CDA be sure and send in your shareware fee! 
  215. David Lyons deserves it.
  216.  
  217. Floyd
  218.  
  219.  
  220.  
  221. Type:      Response       
  222. From:      User797
  223. Date:      88-06-06 19:09:16 EST
  224. 88-06-06 19:09:16 EST
  225. CC:        KatherineL
  226. Re:        Re: CDA's
  227.  
  228. Does NiftyList have a feature where the toolbox call name can be "looked up" by
  229. its number?  That would be particularly helpful to me.  So far, I've had to put
  230. the call into an unused area of memory (usually the upper few bytes of the
  231. keyboard buffer), and listed it.  If I'm not overlooking something, could
  232. someone suggest this to David Lyons?  I'd appreciate it...  /;+/
  233.  
  234. P.S. NL is on my SMALL list of ShareWare I keep and will pay for.
  235.  
  236.  
  237.  
  238. Type:      Response       
  239. From:      Mensch72
  240. Date:      88-06-07 22:18:33 EST
  241. 88-06-07 22:18:33 EST
  242. CC:        KatherineL
  243. Re:        e: CDA's
  244.  
  245. yep, Nifty list will tell ya the name ( it will also tell ya the function
  246. pointer if you ask for it!)
  247.  
  248. Jim
  249.  
  250.  
  251.  
  252.  
  253. Type:      Response       
  254. From:      User797
  255. Date:      88-06-08 17:35:16 EST
  256. 88-06-08 17:35:16 EST
  257. CC:        KatherineL
  258. Re:        Re: CDA's
  259.  
  260. Wellllll.......   HOW?   :}   (Sheepish grin)   /;+/
  261.  
  262.  
  263.  
  264. Type:      Response       
  265. From:      Dave Lyons
  266. Date:      88-07-02 06:04:43 EST
  267. Re:        Nifty List
  268.  
  269. Don't you have a copy of NLIST.DESC, User797?
  270.  
  271. Just type xxxxT, where "xxxx" is the number of the tool call you're interested
  272. in.  It prints the name & toolset name, and it even displays the function
  273. pointer if the thing is in ROM or RAM at the time.  It also sets the "#"
  274. variable to that value, so that you can do a "#L" to see the tool call, or even
  275. put it on the same line:
  276.  
  277.    902T#L
  278.  
  279. would start listing NewHandle for you, for example.
  280.  
  281. If you want to go the OTHER direction it's just as easy:
  282.  
  283.   "Mouse
  284.  
  285. will show you info on all the tool calls that have "Mouse" in their names.
  286.  
  287. Lemme know what you want to see in upcoming versions of Nifty List!
  288.  
  289.  
  290.  
  291. Type:      Response       
  292. From:      MikeW50
  293. Date:      88-07-05 11:05:23 EST
  294. Re:        Re: CDA's
  295.  
  296. Is niftylist available on this BBS for downloading?
  297.  
  298. Mike Westerfield
  299.  
  300.  
  301.  
  302. Type:      Response       
  303. From:      Dave Lyons
  304. Date:      88-07-05 18:38:28 EST
  305. Re:        Nifty List downloading
  306.  
  307. Mike, yes--version 2.22 is in the Utilities forum (Apple-K AUT), under IIgs
  308. Desk Accessories in the libraries.
  309.  
  310. NL 2.4 will be available here when it is finished or when the libraries are
  311. re-opened for uploading, whichever comes *last* :-)
  312.  
  313. --Dave L
  314.  
  315.  
  316.  
  317. Type:      Response       
  318. From:      AFA Gary J
  319. Date:      88-08-13 22:42:00 EST
  320. Re:        Re: CDA's
  321.  
  322. Does anyone know how (or if it is even possible) to obtain the current program
  323. counter value of the program interrupted at the time you enter the control
  324. panel, from within a CDA?  I know that the system stores this information
  325. someplace....because it obviously continues on with its operation right where
  326. it left off upon quitting from the control panel.  Is it obtainable from within
  327. a CDA?
  328.  
  329. Gary
  330.  
  331.  
  332.  
  333. Type:      Response       
  334. From:      AFL Jim
  335. Date:      88-08-14 00:28:33 EST
  336. Re:        Re: CDA's
  337.  
  338. The complete system state is stored, but since it is in one of those
  339. undocumented locations, you can't assume it will stay at that location in
  340. future revisions.
  341.  
  342.  
  343.  
  344. Type:      Response       
  345. From:      Dave Lyons
  346. Date:      88-08-14 01:57:54 EST
  347. Re:        CDA finding old system state
  348.  
  349. Gary, the info is "obtainable" if you don't mean "obtainable in a documented
  350. way."
  351.  
  352. SoftSwitch is one CDA I can think of that definitely finds and even changes the
  353. outside-the-desk-manager system state.  When you leave the CDA
  354. menu--Presto!--you may be in a different 128K world!  I have no idea whether
  355. RWP tried to make Apple promise that their method would continue to work or
  356. whether they just intend to release revised versions of SS when new ROMs and/or
  357. system software comes out.
  358.  
  359. It wouldn't surprise me if some of the state info was actually on the STACK,
  360. but I haven't checked.
  361.  
  362.  
  363.  
  364. Type:      Response       
  365. From:      AFA Gary J
  366. Date:      88-08-14 23:09:50 EST
  367. Re:        Re: CDA's
  368.  
  369. The stack is one of the places I thought of too, but I haven't checked it
  370. either.  It would be the logical place for the program counter.
  371.  
  372. I have done some checking around in bank $E0 and $E1 for the information I
  373. mentioned, but this was some time ago.  I was able to locate where all the
  374. registers were stored, but I couldn't find the program counter.  I guess I'll
  375. check the stack!  Thanks Jim and Dave for your help.
  376.  
  377. Gary
  378.  
  379.  
  380.  
  381. Type:      Response       
  382. From:      MikeW50
  383. Date:      88-08-16 18:31:15 EST
  384. Re:        Re: CDA's
  385.  
  386. You do an RTL to somebody - it shouldn't be too hard to trace the code to see
  387. where they get the info from.
  388.  
  389. Incidentally, if anyone at Apple is listening, it sure seems like this info
  390. should be frozen and preserved.  Some pretty spiff debugging tools could be
  391. written if the mechanism could be counted on!
  392.  
  393. Mike Westerfield
  394.  
  395.  
  396.  
  397. Type:      Response       
  398. From:      AFA Gary J
  399. Date:      88-08-16 20:47:01 EST
  400. Re:        Re: CDA's
  401.  
  402. I agree 100% with what Mike said in the last post about this information being
  403. frozen and documented.  The very reason I am interested in the program counter
  404. value is for debugging purposes.  It could be VERY useful.
  405.  
  406. Gary
  407.  
  408.  
  409.  
  410. Type:      Response       
  411. From:      DataPro
  412. Date:      88-09-30 12:34:00 EST
  413. Re:        CDA's and Visit Monitor
  414.  
  415. I suppose no one has been able to figure out what info is saved or where it is
  416. saved when the Visit Monitor command is envoked or any CDA command is envoked? 
  417. I have all of the information on the IIe/IIc/II+ but as of yet have been unable
  418. to figure out what or where the info (A,X,Y,P,S,PC hi and lo....)is stored in
  419. memory.
  420. Have been able though to locate A,X,Y,P,S in zero page.  What is pushed on
  421. stack I don't know....YET!
  422.  
  423.  
  424.  
  425. Type:      Response       
  426. From:      AFA Gary J
  427. Date:      88-10-01 00:05:41 EST
  428. Re:        Re: CDA's
  429.  
  430. I have been writing a CDA that would automatically display the registers and
  431. program counter when invoked, and I thought I had it all figured out....  BUT,
  432. I seem to be getting inconsistant results.  I may not have all the correct
  433. memory locations.  I'd like some further info as well.
  434.  
  435. Gary
  436.  
  437.  
  438.  
  439. Type:      Response       
  440. From:      AFA Gary J
  441. Date:      88-10-01 00:26:25 EST
  442. Re:        Re: CDA's - register storage
  443.  
  444. The information I was able to drum up on this is as follows:
  445.  
  446. Zero page is stored at               E0/1C00.1CFF
  447. The stack is stored at               E0/0300.03FF
  448. The text screens are at              E0/0C00.1BFF
  449. Accumulator                          E1/0108.0109
  450. X-Register                           E1/010A,010B
  451. Y-Register                           E1/010C.010D
  452. Stack Pointer (S)                    E1/010E.010F
  453. Direct Register (D)                  E1/0110.0111
  454. Data Bank Register (B)               E1/0113
  455. Processor Status (P)                 E1/0114
  456. Program Counter                      2,S
  457. State Register ($C068)               E1/0118
  458. Shadow Register ($C035)              E1/0119
  459. CYA Register ($C036)                 E1/011A
  460. MSlot ($07FB)                        E1/011B
  461.  
  462. Disclaimer:  This information (to the best of my knowledge) is not published by
  463. Apple, therefore it is to be used at your own risk.
  464.  
  465. I have not been able to verify all of this info.  If anyone has any
  466. corrections, additions, or clarifications, please let me know.
  467.  
  468. Gary
  469.  
  470.  
  471.  
  472. Type:      Response       
  473. From:      AFA Gary J
  474. Date:      88-10-09 01:10:18 EST
  475. Re:        Re: CDA's
  476.  
  477. Interesting.... Sandy Mossberg's article in the November issue of
  478. Call-A.P.P.L.E. covers some of the memory locations I listed in the previous
  479. post.  At least now I have a way to verify some of this stuff!  Good article.
  480.  
  481. Gary
  482.  
  483.  
  484.  
  485. Type:      Response       
  486. From:      Matt DTS
  487. Date:      88-10-09 21:09:52 EST
  488. Re:        Re: CDA's
  489.  
  490. Gary:
  491.  
  492. I think you're wasting your time.  The Desk Manager is a tool, and like any
  493. other tool could change its internal workings at any time (even from system
  494. disk to system disk).
  495.  
  496. If you absolute need to be able to stop and look at something for debugging
  497. purposes (which is what I suppose this is for), you can always grab the CDA
  498. vector ($E1/0048 thorugh $E1/004B) and make it point to your own thing.
  499.  
  500. (Note that this is acceptable only for debugging purposes; taking away
  501. IRQ.DSKACC at other times, like during a regular, non-game application, would
  502. be really slimy.  It's slimy during a game, too, but games aren't known for
  503. following any rules at all...)
  504.  
  505. --Matt
  506.  
  507.  
  508.  
  509. Type:      Response       
  510. From:      Matt DTS
  511. Date:      88-10-09 21:16:54 EST
  512. Re:        Re: CDA's
  513.  
  514. I should also point out that the location of IRQ.DSKACC is not guaranteed, and
  515. is provided from the Apple IIgs Firmware Reference (page 268).  It would serve
  516. for debugging purposes but not for the rest of real life.
  517.  
  518. --Matt
  519.  
  520.  
  521.  
  522. Type:      Response       
  523. From:      Dave Lyons
  524. Date:      88-10-09 21:49:49 EST
  525. Re:        intercepting IRQ.DESKACC
  526.  
  527. Matt, the *absolute location* of the IRQ.DSKACC vector isn't guaranteed, as you
  528. say, but getting and setting it with GetVector($12) and SetVector($12) *is*,
  529. right?
  530.  
  531.  
  532.  
  533. Type:      Response       
  534. From:      MikeW50
  535. Date:      88-10-10 10:56:23 EST
  536. Re:        Re: CDA's
  537.  
  538. Matt, many of us have been lamenting the fact that a CDA based debugger is not
  539. possible using strictly legal means.  Could you use your enormous influence at
  540. Apple to get SOME method locked in concreat?  CDA debuggers are too good an
  541. idea to not be iplemented eventually (I'm usrprised there isn't one already). 
  542. If Apple is to lead, rather than follow behind and sweep up the scraps, you
  543. need to establish a common method for finding the regs, and even for signalling
  544. the end of a program.
  545.  
  546. Mike Westerfield
  547.  
  548.  
  549.  
  550. Type:      Response       
  551. From:      Matt DTS
  552. Date:      88-10-10 22:28:54 EST
  553. Re:        Re: CDA's
  554.  
  555. As usual, I can't comment on a CDA debugger or anything like that.
  556.  
  557. But Dave is right - GetVector and SetVector will do the trick in the approved
  558. way.
  559.  
  560. (Can you tell that I had the Firmware Reference here last night but not the
  561. Toolbox Reference?)
  562.  
  563. --Matt
  564.  
  565.  
  566.  
  567. Type:      Response       
  568. From:      MikeW50
  569. Date:      88-10-11 10:29:05 EST
  570. Re:        Re: CDA's
  571.  
  572. Matt,
  573.  
  574. Maybe you misunderstood about the CDA debugger.  I wasn't asking you to comment
  575. on what Apple is doing - I know what is happening in that area (or at least,
  576. what a couple of people wanted to happen as of a recent date - things change
  577. pretty often there).  The point is that others will write debuggers, too. 
  578. After all, you can never have too many debuggers!
  579.  
  580. If the Get/Set vector route is the "approved" way, it sounds great.
  581.  
  582. Mike Westerfield
  583.  
  584.  
  585.  
  586. Type:      Response       
  587. From:      SEGlass
  588. Date:      88-11-05 18:43:06 EST
  589. Re:        CDA Debuggers
  590.  
  591. Yes, a CDA debugger would be great to have except for a strange design quirk in
  592. the way the CDA menu is activated.  You see, the CDA menu is not always entered
  593. via an interrupt.  Several factors can result in a delay from pressing
  594. OA-Control-ESC.
  595.  
  596. The CDA Menu runs in two ways depending whether the event manager is active. 
  597. When the event manager is active, the CDA interrupt handler posts an event and
  598. returns.  When the program calls GetNextEvent, the CDA menu is displayed.
  599.  
  600. When the event manager is not active, the CDA interrupt can invoke the CDA menu
  601. right away, but does not always do so.  Specifically, it does not invoke the
  602. menu if the system busy flag is not zero.  If it is not zero, it schedules a
  603. wake up call with the scheduler and returns.
  604.  
  605. Both of these facts make it impossible to write a good debugger that is a CDA
  606. (You could not get out of an infinate loop if the busy flag were set or the
  607. loop did not call getnextevent).
  608.  
  609. It does not prevent some clever fellow from using the CDA interrupt for a
  610. debugger however.  To make this possible, we at Apple need to provide a clean
  611. way to access the interrupt information.  We'll see what we can do.
  612.  
  613. Steven Glass
  614. Manager, Apple II Toolbox and Imaging
  615. Apple Computer, Inc.
  616.  
  617.  
  618.  
  619. Type:      Response       
  620. From:      JStarta
  621. Date:      88-12-03 00:58:01 EST
  622. Re:        Re: CDA Development Questions
  623.  
  624. Is there a limit as to what a CDA can do? For example, could a CDA be working
  625. in the background while you are doing something else in the foreground?
  626.  
  627. I may be wrong, but you have to set aside a predetermined memory location
  628. depending the background procedure. Right? What, would be a "safe" place to
  629. start?
  630.  
  631. John
  632.  
  633.  
  634.  
  635. Type:      Response       
  636. From:      Dave Lyons
  637. Date:      88-12-03 02:47:53 EST
  638. Re:        CDAs doing work in background
  639.  
  640. John, there are generally no predetermined memory locations in the GS world
  641. (other than for the system's use, and even then most stuff is allocated through
  642. the memory manager, where ever there is room at the time).
  643.  
  644. The Loader will take care of loading your CDA and adjusting any address
  645. references appropriately, depending on where your CDA gets loaded (or where
  646. each segment gets loaded, if you have more than one segment).
  647.  
  648. One way a CDA could do things in the "background" would be to install a
  649. HeartBeat task (see the Misc Toolset folder) so that a routine owned by the CDA
  650. would be called by the system every n/60 of a second.  Of course, the
  651. foreground application always owns things like the screen and
  652. keyboard...probably your CDA would want to do its work and keep the results,
  653. not displaying them until the user entered the main part of your CDA through
  654. the CDA menu.
  655.  
  656. You can install a HeartBeat task when your CDA's "shutdown" entry point is
  657. called.  This happens every time DeskShutDown or DeskStartUp is called, and the
  658. system calls one of those once during boot, right after all the desk
  659. accessories are installed.
  660.  
  661.  
  662.  
  663. Type:      Response       
  664. From:      DougDavies
  665. Date:      88-12-30 13:11:20 EST
  666. Re:        Re: Old state at CDA activation
  667.  
  668. We, at WordPerfect, have written a symbolic debugger that is a CDA.  The status
  669. of the machine (asked earlier) can be found by doing a GetAddr (found in misc.
  670. tools) with a $0009.  This includes all the registers, program counter, etc. 
  671. The return address can be found by using the stack pointer (I think, can't
  672. remember for sure, been a while).  Hope this helps!
  673.  
  674.  
  675.  
  676. Type:      Response       
  677. From:      CompWizA
  678. Date:      89-07-24 20:33:48 EST
  679. Re:        Bringing up the CDA menu
  680.  
  681. How can I bring up the CDA menu from within a program ? By just doing a JSL to
  682. $E1/0048 or by some other means ? BTW I've tried to do a JSL to $E1/0048 my
  683. program crashes with a BRK $00.
  684.  
  685.  
  686.                        CompWizA
  687.  
  688.  
  689.  
  690.  
  691. Type:      Response       
  692. From:      Dave Lyons
  693. Date:      89-07-25 22:52:17 EST
  694. Re:        CDA menu under program control
  695.  
  696. Hmmm...if the Event Manager is on, I bet you can call PostEvent with a
  697. deskAccEvent.  Otherwise I'm pretty much stumped...you *may* be able to use the
  698. ADB SendInfo call to make the machine think the user hit Apple-Ctrl-Esc...then
  699. again, you may not be able to (I haven't tried, and you might have to discover
  700. the right keycode experimentally even if it works).
  701.  
  702.  
  703.  
  704. Type:      Response       
  705. From:      CompWizA
  706. Date:      89-07-26 18:41:42 EST
  707. Re:        PostEvent won't do it
  708.  
  709. The Event Manager is active but I'm not using GetNextEvent. I've tried using
  710. just PostEvent and PostEvent with GetNextEvent but nothing happens. The routine
  711. that the vector at $E1/0048 points to just does just a PostEvent but exits in 8
  712. bit mode so my program crashes. I've tried doing a REP $30 right after I do the
  713. JSL to the vector but nothing happens unless I insert a BRK $00 somewhere after
  714. it. NOTHING seems to work.
  715. BTW I looked at SendInfo but how do I send the Control and Open Apple key codes?
  716.  
  717.                         CompWizA
  718.  
  719.  
  720.  
  721. Type:      Response       
  722. From:      AFA Parik
  723. Date:      89-07-28 20:29:00 EST
  724. Re:        you're doing it wrong...
  725.  
  726.  
  727.  
  728. you need to ENTER in short mode (as with any interrupt).  the following works.
  729.  
  730.  
  731.  
  732.            short m,i
  733.            jsl $E10048
  734.            long m,i
  735.  
  736. simple!
  737.  
  738.  
  739.  
  740. Type:      Response       
  741. From:      CompWizA
  742. Date:      89-07-30 15:10:03 EST
  743. Re:        It doesn't work
  744.  
  745. I don't speak APW but I translated the macros to this in assembly:
  746.  
  747.           SEP $30
  748.           Tell the assembler to only put out 8 bit opcodes
  749.           REP $30
  750.           Tell the assembler to put out 16 bit opcodes
  751.  
  752. The problem: it doesn't work I my program just goes right on chugging along as
  753. if I never made a JSL to the vector.
  754.  
  755.                          CompWizA
  756.  
  757.  
  758.  
  759. Type:      Response       
  760. From:      AFA Parik
  761. Date:      89-07-31 23:40:06 EST
  762. Re:        Re: CDA's
  763.  
  764. Hmm, not sure CompWhiz.  The easiest thing to do is disassemble the control
  765. panel (I did it, its VERY simple, all it does is check if the CP is callable by
  766. checking $E01D67 [whether the user is in the CP or not already] and $E100FF
  767. [the busy flag] and if all conditions are a-o.k. then it calls a few toolbox
  768. routines which handle all CDA stuff)
  769.  
  770. Also if you're using merlin, sep #$30 and rep #$30 i think need to be preceeded
  771. by MX %11 and MX %00 respectively (I think?) 
  772.  
  773.  
  774.  
  775. Type:      Response       
  776. From:      CompWizA
  777. Date:      89-08-04 19:31:23 EST
  778. Re:        Must call GetNextEvent
  779.  
  780. OK, here's what it was YOU MUST CALL _GETNEXTEVENT AFTER A JSL TO THE CDA
  781. VECTOR otherwise the cda manager will not be called to display the Control
  782. Panel.
  783.  
  784.  
  785.                       CompWizA
  786.